1. Technical Field
The present invention relates to an HTTP server compatible with a chunked transfer coding and a computer readable medium storing a program therefor.
2. Description of Related Art
As on of the responses to an HTTP (Hypertext Transfer Protocol) request, there is a response by chunked transfer coding, the detail of which is defined by Hypertext Transfer Protocol, RFC (Request for Comments) 2616 of HTTP/1.1. The chunked transfer coding is a transfer coding for dividing data into several chunks as a response to the HTTP request.
For example, Unexamined Japanese Patent Application Publication No. 2004-208266 discloses a technology for transferring chunked tile parts of the JPEG 2000 compliant codestream.
Conventionally, in case of inquiring the server about the job status in a printer on the network, a connection is initiated from the client to the server to request the status of the printer or the job. Then, the server returns a single status report to the client, and disconnects or terminates the communication thereafter. Thus, if the client attempts to successively or cyclicly acquire the status of the printer, a series of operations, each including the initiation of the connection, the transmission of the request, the response to the request, and the termination, are required. In this method, there have been problems that: a communication overhead is large; the process load increases in both a server and a client; and a mismatch may occur between the actual status in the printer and the status comprehended on the client side, depending on the length of the transmission cycle of the request for the status report.
For example, in FIG. 10, a notification of job list is requested (Req) by connecting from a client to a printer controller having a server function. As the response (Res) to the request, the job list is replied one time. Then the communication is terminated. The job list in the client side is updated by repeating the series of communication set H at a constant cycle.
In this example, since the communication sets H2 and H6 were conducted after the previous communication sets H1 and H5 had been conducted and before the job statuses of the printer controller side have changed, the communication sets H2 and H6 becomes useless communication sets having no new information to be notified to the client.
Further, from the time T1 when the response (Res) is transmitted from the printer controller to the client in the communication set H2 to the time T4 when the response (Res) is transmitted in the communication set H3, a job of ID3 is newly submitted at time T2 and the print of the first page is completed in the printer controller at time T3. Thus, the information when the job of ID3 was submitted is skipped without being displayed.
The times (T4, T6, T8 and T10), when the changes are reflected to the job list of the client side, delay from the times (T2, T3, T5, T7 and T9), when the job statuses have changed in the printer controller side, in a time-wise. In the delay period, the mismatch of the job statuses between the printer controller side and the client side exists.
The problems, such as a communication overhead being large, the process load increasing in both the server and the client; and a mismatch occurring between the statuses comprehended by the server side and the client side, may occur not only in the case where the client monitors the printer status but also in the cases of any monitoring objects.